In a configuration system, a user can define and store in a configuration database configuration properties (e.g., key value pairs) that a service can read and then use to alter its behavior. In a typical configuration system, the records of a configuration database include the name or identify of the service, the property name, an environment or host identifier, and a value for the configuration property. The value can be a default value, a value for a data center, a value for a particular host, or a value for all hosts. For example, a service that posts job openings can have a name of JobSearcher and can include a configuration property for that particular service such as the maximum number of queries that it can handle during a particular time period. That configuration property can also include, for example, a default value of 300 maximum queries, and can have maximum queries of 250 and 350 for a first data center and a second data center respectively. Such a record in the configuration database could resemble the following:
(JobSearcher, MaxQPS, default:300, DataCenterOne: 250, DataCenterTwo:350)
Configuration systems normally include static configuration properties and dynamic configuration properties. Static configuration properties are only needed at the time of system start up, so they need not be supplied during the execution of a service. However, if a static parameter does have to change, it requires a code commit, the building and deployment of a new configuration, and the restarting of the service to implement the new configuration. Examples of typical static configuration properties include the maximum amount of processing memory, a database's internet protocol (IP) address, and the version of Java being used by the service. Other configuration properties can be dynamic in nature, that is, they are amenable to change while the service is running. However, to implement the change of the dynamic configuration property, the system must be restarted. Examples of typical dynamic properties include the maximum queries per second permitted by a service, a throttle factor, and an identification of a black/white list.
There are inherent problems associated with the static nature of a configuration system, and in particular, changing the value of a dynamic property in a static configuration system. First, typically only software engineers can make changes to configuration properties. Second, it can take hours to roll out a new configuration property for a service. Such a limitation is quite unacceptable for a typical online service. Third, restarting a service has side effects such as downtime, the loss of in-memory caches, and the monitoring of metric spikes and dips.
In some systems, developers overcome and/or work around the static nature of a configuration system by using a test or experimental system to pass configuration properties to a commercial or production system. However, this is really a misuse of the test system and it comes with its own problems and issues. For example, a test system may not be able to support all types of values such as integer, double, Boolean, and lists of integers, doubles, strings, and/or Booleans. Furthermore, the test system may not be able to define different values for different data centers and/or different hosts, and a test system may not always be available and up and running.
Consequently, a new method is needed to handle a configuration property system, and in particular, dynamic configuration properties.